API for request MCUboot mode by the application #44512
Conversation
Placed all dependent properties in one if statement. Signed-off-by: Andrzej Puzdrowski <[email protected]>
soc/arm/nordic_nrf/nrf51/soc.c
Outdated
| @@ -30,6 +30,20 @@ extern void z_arm_nmi_init(void); | |||
| #define LOG_LEVEL CONFIG_SOC_LOG_LEVEL | |||
| LOG_MODULE_REGISTER(soc); | |||
|
|
|||
| int soc_boot_mode_set(uint8_t mode) | |||
| { | |||
| nrf_power_gpregret2_set(NRF_POWER, mode); | |||
Introduced the API which allows the Application to request a specific bootloader mode and the MCUboot to obtain it. MCUboot might enter this mode once system reboot. Implementations of this will use SoC specific resources, like a reset retention register. Signed-off-by: Andrzej Puzdrowski <[email protected]>
nvlsianpu
force-pushed
the
boot/boot_mode_set
branch
from
d7d19ac to
e76f2a3
Compare
nvlsianpu
requested review from
nashif,
carlescufi,
galak,
MaureenHelm and
anangl
as code owners
nvlsianpu
force-pushed
the
boot/boot_mode_set
branch
from
e76f2a3 to
3c39517
Compare
nvlsianpu
force-pushed
the
boot/boot_mode_set
branch
from
3c39517 to
1c3e9df
Compare
Implemented SoC specific function needed for posting the bootloader mode by the application and fetching it by the MCUboot. Signed-off-by: Andrzej Puzdrowski <[email protected]>API for request MCUboot mode
nvlsianpu
force-pushed
the
boot/boot_mode_set
branch
from
1c3e9df to
8fb78c4
Compare
|
@plskeggs FYI |
| #ifndef ZEPHYR_INCLUDE_MCUBOOT_BOOT_MODE_H_ | ||
|
|
||
| #define BOOT_MODE_REQ_NORMAL 0x00 | ||
| #define BOOT_MODE_REQ_RECOVERY_DFU 0x01 |
There was a problem hiding this comment.
It's been a while since I've looked at zephyr's MCUboot related APIs, but I'm confused about this mix of "MCUBOOT" and "BOOT" in the namespace. Is this meant to be MCUboot-specific, or generic across all bootloaders?
If it is meant to be mcuboot-specific, is there any harm in using MCUBOOT consistently? (I think this is the real question I am trying to ask.)
If it is meant to be generic, why is MCUBOOT appearing sometimes here?
| @@ -47,6 +47,22 @@ extern void z_arm_nmi_init(void); | |||
| #define LOG_LEVEL CONFIG_SOC_LOG_LEVEL | |||
| LOG_MODULE_REGISTER(soc); | |||
|
|
|||
| int soc_mcuboot_mode_set(uint8_t mode) | |||
There was a problem hiding this comment.
Nothing wrong with this line of code, but the Signed-off-by: line in the commit message has the wrong format.
| @@ -47,6 +47,22 @@ extern void z_arm_nmi_init(void); | |||
| #define LOG_LEVEL CONFIG_SOC_LOG_LEVEL | |||
| LOG_MODULE_REGISTER(soc); | |||
|
|
|||
| int soc_mcuboot_mode_set(uint8_t mode) | |||
| { | |||
| nrf_power_gpregret2_set(NRF_POWER, mode); | |||
There was a problem hiding this comment.
From spot-checking a product specification, the GPREGRET and GPREGRET2 registers seem to be available for application developer use too. Is there any risk in using them for this purpose?
There was a problem hiding this comment.
GPREGRET is used by NCS internally for instance, it is also place where nRF SoC stores reboot-type in zephyr.
There was a problem hiding this comment.
I can use GPREGRET for transfer both the reboot-type and the recovery-dfu request. This implies that I need to introduce an API for retrieve reboot-type as well.
What your opinion @mbolivar
There was a problem hiding this comment.
Sorry, I don't understand your last comment
There was a problem hiding this comment.
If you see usage of GPREGRET2 as the waste of resources I can make a better solution:
The idea would be to start using GPREGRET for request of recovery-dfu as well (along with reboot-type to keep of which it is used currently).
As intermediate steep I would implement API for retrieve reboot-type as there is sys_arch_reboot(int type) call but there is no a counterpart to it which would allows to check what a reboot-type was used.
Of course this mean that zephyr common API for get reboot type will be needed:
there is void sys_reboot(int type) but zephyr doesn't have API for retrieve the type
@mbolivar-nordic What is your opinion on that ^^ idea?
There was a problem hiding this comment.
Ah, OK, I think I understand now. No, if we're already using GPREGRET, from my side I see no harm in using GPREGRET2 as well. You're saying you're not aware of any customers already using this that will be negatively impacted, right?
There was a problem hiding this comment.
alternative: #46084
|
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
|
This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time. |
|
superseded by #50864 |
This API is added in order to make possible entering the DFU recovery mode by MCUboot if application has requested that.
PR which enable possibility for MCUBoot recovey on the application demnd